This is in draft because before delivering I need to:

• Add unit tests - I guess they will have to be in python?
• Answer some questions:
  • Shouldn't AuthStack be used in checkAuthSys too?
  • Is one AuthStack instance per service sufficient? I think it might be okay to share the same stack between isAuth and isReject, but perhaps need a different stack if this is also added to checkAuthSys...

• Shouldn't AuthStack be used in checkAuthSys too?

Recursion in account auth doesn't really work with checkAuthSys. Recursion only works with a multisig that allows failure of some nested calls without aborting.

• Is one AuthStack instance per service sufficient? I think it might be okay to share the same stack between isAuth and isReject, but perhaps need a different stack if this is also added to checkAuthSys...

Technically what we want is one auth stack per top-level call. Actually, I think the easiest way to get fully correct semantics is to pass the stack as a parameter. An auth service that delegates would need to add the current account to the stack before the nested calls. Non-delegating auth services can safely leave off the extra parameter, and the extra data will be ignored. The extra size will not be a problem, because the wasm stack will overflow first (I think the current limit is 255 recursive actions).